Extract CVCMerkleProof from the VC creation#226
Extract CVCMerkleProof from the VC creation#226william-brooks wants to merge 6 commits intodevelopfrom
Conversation
…r supporting features that rely on CvcMerkleRoot like attestations
| @@ -0,0 +1,59 @@ | |||
| /* eslint-disable @typescript-eslint/no-explicit-any */ | |||
There was a problem hiding this comment.
Instead of doing this file wide could we do this next to the any usage :)
There was a problem hiding this comment.
I've made the change where it makes sense... there is one file that is completely riddled with anys
|
|
||
| const vm = await didUtil.findVerificationMethod(did, this._verificationMethod); | ||
|
|
||
| if(!vm) return false; |
There was a problem hiding this comment.
No... it was like that... but, following suite on other libraries, if it is unable to verify (for whatever reason) return false
| import validUrl from 'valid-url'; | ||
|
|
||
| function validIdentifiers() { | ||
| const vi = _.map(definitions, (d: { identifier: any; }) => d.identifier); |
There was a problem hiding this comment.
I think we should use the typescript array functions instead of lodash?
There was a problem hiding this comment.
Lodash is all over... mostly just copy/paste from the existing implementation
There was a problem hiding this comment.
I have created a separate ticket for this
| identifier: this.identifier, | ||
| expirationDate: this.expirationDate, | ||
| version: this.version, | ||
| // version: this.version, |
There was a problem hiding this comment.
I added a TODO with ticket number
src/vc/VerifiableCredential.ts
Outdated
| } | ||
| } | ||
|
|
||
| isMatch = (constraints: any) => { |
There was a problem hiding this comment.
I think we should stay consistant with our types of functions? What do you think?
There was a problem hiding this comment.
Agreed, mostly because I'd spend another few days fixing pre-existing broken types
There was a problem hiding this comment.
Sorry I totally misunderstood you - ignore previous comment.
Agreed, fixing
| if(!foundKey) { | ||
| throw new Error(`No Verification Method found for ${iri}`); | ||
| } | ||
| const foundKey = doc.verificationMethod?.find((pk: any) => pk.id.startsWith(iri)); |
There was a problem hiding this comment.
should we check if foundKey is undefined ?
There was a problem hiding this comment.
This would silently fail (correctly imo), but have updated it to be more explicit
| const unsignedCred = await VerifiableCredential.create({ | ||
| issuer: didTestUtil.DID_CONTROLLER, | ||
| identifier: 'credential-cvc:Identity-v3', | ||
| subject: credentialSubject, | ||
| claims: [name, dob], | ||
| expiry: null, | ||
| }); |
There was a problem hiding this comment.
In general, if we're copying large blocks of boilerplate code over and over, we need to please refactor it into a single location.
tbarri
left a comment
There was a problem hiding this comment.
This is a fairly large commit, and no doubt valuable work. Thank you for putting the effort into this. Something for the future though:
Try break the PR into even smaller commits, and squash the commits that don't matter. For example, commit Extracted CvcMerkleProof with tests doesn't contain anything meaningful. As such, it shouldn't be in this PR. There's 6 commits all named Extract CVCMerkleProof from the VC creation.
Similarly, if you make large sweeping reformat changes as was done in Updates to support CvcMerkleRoot as separate to a VC, along with others, please keep it in a separate commit. It's almost impossible to separate your logic from the reformat changes.
Ideally, we want the PRs to be presented as you intend to merge them. Working diffs need to please be squashed / merged / dropped before sending out for review.
Please don't stress about this PR series - but let's keep this in mind for the next PR :)
| const signer = createSigner(document, keypair); | ||
|
|
||
| const credential = await createCredential(document, signer, keyResolver); | ||
| const cvcMerkleProof = new CvcMerkleProof(signer); | ||
|
|
||
| const credential = await createCredential(document, cvcMerkleProof); | ||
|
|
||
| const verified = await credential.verifyMerkletreeSignature(); | ||
| const verified = await cvcMerkleProof.verify(credential); | ||
|
|
||
| expect(verified).toBe(true); |
There was a problem hiding this comment.
I think it would be really valuable if we wrote these unit tests in terms of the interfaces (export default interface Proof<K>). This way, we can drop any concrete implementation into the unit tests, and validate that they work.
This update separates the CvcMerkleProof from VC creation allowing for alternative proof mechanisms to be used. PR: #226 Signed-off-by: William Brooks <william@identity.org> Reviewed-by: Julian Spring <julianspring@identity.org> Reviewed-by: Tighe Barris <4658684+tbarri@users.noreply.github.com>
6ed9936 to
941d73e
Compare
This update separates the CvcMerkleProof from VC creation allowing for alternative proof mechanisms to be used. PR: #226 Signed-off-by: William Brooks <william@identity.org> Reviewed-by: Julian Spring <julianspring@identity.org> Reviewed-by: Tighe Barris <4658684+tbarri@users.noreply.github.com>
941d73e to
24026f5
Compare
This update separates the CvcMerkleProof from VC creation allowing for alternative proof mechanisms to be used. PR: #226 Signed-off-by: William Brooks <william@identity.org> Reviewed-by: Julian Spring <julianspring@identity.org> Reviewed-by: Tighe Barris <4658684+tbarri@users.noreply.github.com>
a6f5cac to
941d73e
Compare
This update separates the CvcMerkleProof from VC creation allowing for alternative proof mechanisms to be used. PR: #226 Signed-off-by: William Brooks <william@identity.org> Reviewed-by: Julian Spring <julianspring@identity.org> Reviewed-by: Tighe Barris <4658684+tbarri@users.noreply.github.com>
941d73e to
ae6a8fc
Compare
This update separates the CvcMerkleProof from VC creation allowing for alternative proof mechanisms to be used.
PR: #226
Signed-off-by: William Brooks william@identity.org
Reviewed-by: Julian Spring julianspring@identity.org
Reviewed-by: Tighe Barris 4658684+tbarri@users.noreply.github.com